Research perspectives on Bitcoin and second-generation cryptocurrencies

Bitcoin has emerged as the most successful cryptographic currency in history. Within two years of its quiet launch in 2009, Bitcoin grew to comprise billions of dollars of economic value, even while the body of published research and security analysis justifying the system’s design was negligible. In the ensuing years, a growing literature has identified hidden-butimportant properties of the system, discovered attacks, proposed promising alternatives, and singled out difficult future challenges. This interest has been complemented by a large and vibrant community of open-source developers who steward the system, while proposing and deploying numerous modifications and extensions. We provide the first systematic exposition of the second generation of cryptocurrencies, including Bitcoin and the many alternatives that have been implemented as alternate protocols or “altcoins.” Drawing from a scattered body of knowledge, we put forward three key components of Bitcoin’s design that can be decoupled, enabling a more insightful analysis of Bitcoin’s properties and its proposed modifications and extensions. We contextualize the literature into five central properties capturing blockchain stability. We map the design space for numerous proposed modification, providing comparative analyses for alternative consensus mechanisms, currency allocation mechanisms, computational puzzles, and key management tools. We focus on anonymity issues in Bitcoin and provide an evaluation framework for analyzing a variety of proposals for enhancing unlinkability. Finally we provide new insights on a what we term disintermediation protocols, which absolve the need for trusted intermediaries in an interesting set of applications. We identify three general disintermediation strategies and provide a detailed comparative cost analysis. I. WHY BITCOIN IS WORTHY OF RESEARCH Consider two opposing viewpoints on Bitcoin in straw-man form. The first is that “Bitcoin works in practice, but not in theory.” At times devoted members of the Bitcoin community espouse this philosophy and criticize the security research community for failing to discover Bitcoin, not immediately recognizing its novelty, and still today dismissing its importance due to a lack of rigorous theoretical foundation. A second viewpoint is that Bitcoin hopelessly relies on an unknown combination of socio-economic factors for its current stability which are intractable to model with sufficient precision, failing to yield a convincing argument for the system’s soundness. Given these difficulties, experienced security researchers may avoid Bitcoin as a topic of study, considering it prudent security engineering to only design systems with precise threat models that admit formal security proofs. We strongly dismiss both of these simplistic approaches and show where each viewpoint fails, forwarding new insights based on multiple examples of existing knowledge. To the first, we contend that while Bitcoin has worked surprisingly well in practice so far, there is an important role for research to play in identifying precisely why this has been possible, moving beyond a blind acceptance of the informal arguments presented with the system’s initial proposal. Furthermore, it is crucial to understand whether Bitcoin will still “work in practice” as practices change. We expect external political and economic factors to evolve, and the system must change if and when transaction volume scales, and the nature of the monetary rewards for Bitcoin miners will change over time as part of the system design. It is not enough to argue that Bitcoin has worked from 2009–2014 and will therefore continue likewise. We do not yet have sufficient understanding to conclude with confidence that Bitcoin will continue to work well in practice, and that is a crucial research challenge that requires insight from computer science theory. To the second viewpoint, we contend that Bitcoin is filling an important niche by providing a virtual currency system without any trusted parties and without pre-assumed identities among the participants. Within these constraints, the general problem of consensus in a distributed system is impossible [5], [81] without further assumptions like Bitcoin’s premise that rational (greedy) behavior can be modeled and incentives can be aligned to ensure secure operation of the consensus algorithm. Yet these constraints matter in practice, both philosophically and technically, and Bitcoin’s approach to consensus within this model is deeply surprising and a fundamental contribution. Bitcoin’s core consensus protocol also has profound implications for many other computer security problems beyond currency1 such as distributed naming, secure timestamping and commitment, generation of public randomness, as well as many financial problems such as self-enforcing (“smart”) contracts, decentralized markets and order books, and distributed autonomous agents. In short, even though Bitcoin is not easy to model, it is worthy of considerable research attention as it may form the basis for practical solutions to exceedingly difficult and important problems. II. OVERVIEW OF BITCOIN A. A Contextualized History We refer the interested reader to existing surveys on the “first wave” of cryptocurrency research [13], [82]. In short, cryptographic currencies date back to Chaum’s proposal for 1As we shall see, it may not be possible to remove the currency functionality and still have a working consensus system. “untraceable payments” in 1983 [22], a system involving bankissued cash in the form of blindly signed coins. Unblinded coins are transferred between users and merchants, and redeemable after the bank verifies they have not been previously redeemed. Blind signatures prevent the bank from linking users to coins, providing unlinkability akin to cash. Throughout the 1990s, many variations and extensions of this scheme were proposed. Significant contributions include: removing the need for the bank to be online at purchase time [23], allowing coins to be divided into smaller units [80] and improving efficiency [21]. Several startup companies including DigiCash [95] and Peppercoin [87] attempted to bring electronic cash protocols into practice but ultimately failed in the market. In fact, no schemes from this “first wave” of cryptocurrency research achieved significant deployment. Moderately hard “proof-of-work” puzzles were proposed in the early 1990s for combatting email spam [34] (although it was never widely deployed for this purpose [59]). Many other applications followed, including proposals for a fair lottery [41], minting coins for micropayments [88], and preventing various forms of denial-of-service and abuse in anonymous networks [8]. The latter, Hashcash, was an alternative to using digital micropayments (e.g., NetBill [98] and Karma [107]). Proof of work was also used to detect sybil nodes in distributed peer-to-peer consensus protocols [5], and is used in Bitcoin consensus for a similar reason. Another essential element of Bitcoin is the public ledger, which makes double-spending detectable. In auditable ecash [93], [94], proposed in the late 1990s, the bank maintains a public database to detect double-spending and ensure the validity of coins, however the notion of publishing the entire set of valid coins was dismissed as impractical (only a Merkle root was published instead). B-money [29], proposed in 1998, appears to be the first system where all transactions are publicly (anonymously) broadcast and stored. Proposed on the Cypherpunks mailing list, b-money received minimal attention from the academic research community. Smart contracts [102], proposed in the early 1990s, enable parties to formally specify an enforceable agreement using cryptography and scripts. This idea portends Bitcoin’s scripting capabilities. In 2008, Bitcoin was announced and a white paper penned under the pseudonym Satoshi Nakamoto was posted to the Cypherpunks mailing list [77], followed quickly the source code of the original reference client. Bitcoin’s genesis block was mined on or around January 3, 2009.2 The first use of Bitcoin as a currency is thought to be a transaction in May 2010, where one user ordered pizza delivery for another in exchange for 10 000 bitcoins. Since then, increasing number of merchants and services have incorporated Bitcoin in some way, and the price has generally risen, reaching a peak of approximately $1400USD per coin in July 2013. Bitcoin’s history has also been colored by association with 2Famously, the first block contains the string “The Times 03/Jan/2009 Chancellor on brink of second bailout for banks.” crime. Bitcoin was famously used in a black market website, Silk Road [24], which operated from Feb. 2011 until Oct. 2013 when it was seized and shut down by the FBI. Botnets have found Bitcoin mining to be a supplemental source of income [46]. A current US federal court case involves a large Bitcoin-based Ponzi scheme [97]. In 2014, a computer virus called CryptoLocker extorted millions of dollars from victims by encrypting their files and demanding a Bitcoin ransom to release the decryption key [38]. Many users’ Bitcoins have been lost due to theft [33] and collapsed exchanges [75]. B. A Technical Overview We present Bitcoin’s current operation through its three main technical components: transactions (including scripts), the consensus protocol, and the communication network. Bitcoin is exceedingly complex—our goal is to present the system with sufficient technical depth, so the extant literature on Bitcoin, reviewed and evaluated in later sections of this paper, becomes understandable. In particular, a key benefit of our three-component breakdown is that it makes evaluating and systematizing proposed changes (Sections V & VIII) insightful by “decoupling” concepts that may be changed independently. Sources of information on Bitcoin. Bitcoin can be difficult to define as there is no formal specification. The original Bitcoin white paper [77] provides a good overview of Bitcoin’s design philosophy but many important technical details are omitted or out-dated. The reference implementation bitcoind is considered a de facto specification, with further knowledge scattered across a series of “Bitcoin Improvement Proposals” (BIPs), forum postings, online wiki articles, the developer mailing list, and logged IRC discussions.3 We systemize these sources into a precise technical introduction, putting forward the components of the system we consider to be independent design decisions. 1) Transactions & Scripts: The state of the world in Bitcoin is represented by a series of messages called transactions. Among other possibilities, transactions are foremost published to transfer quantities of currency from one user to another. It is important to note that the large (and growing) list of transactions is the only state in Bitcoin. There is no built-in notion of higher-level concepts such as users, account balances or identities—these all exist only to the extent that they can be imputed by analyzing the list of all published transactions. Transaction format. A transaction is an array of inputs and an array of outputs. The entire transaction is hashed using SHA256 and this hash serves as its globally unique transaction ID. Transactions are represented using an ad hoc binary format; this is an early example of an important detail for which bitcoind is the de facto specification. Each output contains an integer value representing a quantity of the Bitcoin currency. The precision of this value immediately limits the extent to which units of the currency 3Which can be found, respectively, at: https://bitcointalk.org/, https://bitcoin.it/, [email protected], irc: //freenode.net/#bitcoin-dev, and irc://freenode.net/#bitcoin-wizards can be sub-divided; the smallest unit is called a satoshi. By convention, 10 satoshis is considered the primary unit of currency, called one “bitcoin”4 and denoted XBT, BTC or B. Each output also has a short code snippet in a special scripting language called the scriptPubKey representing the conditions under which that transaction output can be redeemed, that is, included as an input in a later transaction. Transaction scripts. Typically, the scriptPubKey specifies the hash of an ECDSA public key and a signature validation routine. This script can be redeemed by signing the entire redeeeming transaction using the specified key and is called a “pay-to-pub-key-hash” transaction. The vast majority of Bitcoin transactions are pay-to-pub-key-hash and the system is often described with this being the only possibility, although other transaction types are possible. The scripting language is an ad hoc, non-Turing-complete stack language with fewer than 200 commands called opcodes. They include support for cryptographic operations—e.g., hashing data and verifying signatures. Like the transaction format, the scripting language is only specified by its implementation in bitcoind. Transaction inputs refer to previous transactions by their transaction hash and the index of the output within that transaction’s output array. They must also contain a code snippet which “redeems” that transaction output called the scriptSig. To successfully redeem a previous transaction, the concatenated scriptSig and scriptPubKey must form a program which executes successfully. For pay-to-pub-key-hash transactions, the scriptSig is simply a public key and a signature. Conservation of value. In addition to the requirements that each input of a transaction matches a previous transaction output, and each concatenated script successfully redeems the claimed inputs, transactions are only valid if they satisfy the fundamental constraint that the sum of the values of all transaction outputs is less than or equal to the sum of the values of all inputs. We discuss in Section II-B2 the one exception: the coinbase transaction used to create new units of currency. From transactions to ownership. By themselves, this format of transaction implies several interesting properties. There is no inherent notion of identities or individual accounts which “own” bitcoins. Ownership simply means knowing a private key which is able to make a signature that redeems certain outputs—an individual owns as many bitcoins as they can redeem. Public key hashes, as specified in pay-to-pubkey-hash transactions, effectively function as pseudonymous identities within the system and are referred to as addresses. No linking is required to a user’s real-world name or identi-